Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/pieces/community/customer-finder/package.json`:
- Line 6: The package.json "main" entry currently points to TypeScript source
("src/index.ts") which is incorrect; either remove the "main" field or update it
to point to the compiled output (e.g., "dist/out-tsc/index.js" or the project's
compiled entry) so consumers resolve JS at runtime; update the package.json
"main" key accordingly and ensure it matches the output path produced by the
build step used by publish-piece.ts.

In `@packages/pieces/community/customer-finder/src/lib/actions/find-leads.ts`:
- Around line 35-39: The generated email domain uses companyName with only
spaces stripped, which allows invalid characters (e.g., "&", punctuation,
accents); update the code in find-leads.ts where companyName is built and where
email is created to sanitize and normalize the domain: transform companyName to
lowercase, replace ampersands with "and", remove or replace any non-alphanumeric
characters (excluding hyphen), strip diacritics/accents, and collapse multiple
separators before appending the TLD so the email in the leads.push entry is
always a valid domain string.

In
`@packages/server/api/src/app/database/migration/postgres/1745000000000-AddVirtualToolsToMcp.ts`:
- Around line 1-19: Add the new migration class
AddVirtualToolsToMcp1745000000000 to the migration registration so it runs:
import AddVirtualToolsToMcp1745000000000 from the postgres migration file and
insert it into the commonMigration array in postgres-connection.ts in correct
timestamp order; then create a SQLite equivalent migration file named
1745000000000-AddVirtualToolsToMcpSqlite.ts that uses SQLite syntax (ALTER TABLE
"mcp" ADD COLUMN "virtualTools" TEXT) and import/register that new migration in
sqlite-connection.ts (add to the migrations array) so dev/test DBs match
production.

In `@packages/server/api/src/app/mcp/mcp-server.ts`:
- Around line 160-167: The mapped lookup of actions in blendedActions can
produce undefined when metadata.actions[ba.actionName] is missing; update the
vt.baseActions mapping (the async function inside Promise.all that calls
pieceMetadataService(...)) to validate the lookup result: assign const action =
metadata.actions[ba.actionName]; if (!action) throw a clear error (including
ba.pieceName and ba.actionName and projectId/platformId) or otherwise
filter/handle the missing case before returning, so blendActions is never called
with undefined.

In `@packages/server/api/src/app/mcp/virtual-tool-service.ts`:
- Around line 43-45: The loop over ruleSets destructures { conditions, targets }
from each rule but doesn't guard against missing properties; change the logic in
the rule processing (the for ... of ruleSets block that computes conditionMet)
to validate and coerce these fields before use (e.g., treat missing/non-array
conditions as an empty array so conditions.every(...) is safe and verify targets
is an array before iterating/using it), and add a short early-continue or
error-log if a rule's structure is invalid; update the computation that sets
conditionMet and any subsequent use of targets in the same block (referencing
the rule variable, conditions, targets, and conditionMet) to rely on these
defensive checks.

---

Nitpick comments:
In
`@packages/pieces/community/customer-finder/src/lib/actions/generate-outreach.ts`:
- Around line 33-37: The current generator (in the function that reads `tone`,
`customer_name`, and `product_service`, e.g., generateOutreach) treats any
unknown `tone` as casual; add an explicit validation branch: handle known values
explicitly (e.g., "professional" and "casual") and for any other `tone` return a
clear error or throw an exception (TypeError) indicating an unsupported tone
value so callers fail fast and it’s obvious when input contracts drift; update
the branch logic to reference `tone`, `customer_name`, and `product_service` so
the new validation replaces the implicit fallback.

In `@packages/server/api/src/app/mcp/mcp-server.ts`:
- Around line 172-173: Virtual tool registrations call server.tool with vt.name
but don't truncate names; apply the same MAX_TOOL_NAME_LENGTH enforcement as
elsewhere by slicing vt.name to MAX_TOOL_NAME_LENGTH before passing to
server.tool (same pattern used at other registrations such as the ones around
server.tool calls at lines near 60 and 211). Update the invocation that uses
vt.name to pass vt.name.slice(0, MAX_TOOL_NAME_LENGTH) so virtual tool names are
consistently bounded.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/pieces/community/customer-finder/README.md`:
- Line 8: Update the README description for the customer-finder piece to make it
explicit that lead discovery is simulated rather than performing real-world
lookups; edit the sentence "Finds target customers based on a niche and location
using AI-driven discovery." in the package README for the customer-finder piece
to state that results are synthetic/simulated AI-generated leads for
demonstration or prototyping (mention "simulated" or "synthetic" and add a short
qualifier like "for demo/prototyping purposes, not real-world contact data").

---

Nitpick comments:
In `@packages/pieces/community/customer-finder/.eslintrc.json`:
- Around line 8-31: Merge the three empty override objects inside the overrides
array into a single override entry: replace the separate objects that list
["*.ts","*.tsx","*.js","*.jsx"], ["*.ts","*.tsx"], and ["*.js","*.jsx"] (each
with empty "rules") with one override containing the combined "files" pattern
(e.g., ["*.ts","*.tsx","*.js","*.jsx"]) and a single empty "rules" object,
removing the redundant override objects; ensure you update the "overrides" array
to contain only that consolidated override.